@ShaneKilloran this looks like a cool tool. Am I correct though that the base tool - the jit debug tool - lives in a non-openj9 repo? Would it be possible to have that tool contributed to openj9 first before working through this PR?

Are there limitations to this tool? In particular, the implementation of reflect is changing to use MethodHandles. Does that change how this tool needs to transform the bytecode?

@ShaneKilloran this looks like a cool tool. Am I correct though that the base tool - the jit debug tool - lives in a non-openj9 repo? Would it be possible to have that tool contributed to openj9 first before working through this PR?

@DanHeidinga You are correct, this tool is requires some of the changes from the https://github.com/r30shah/openj9-jit-debug-agent that we needed to upstream after cleaning up. I am planning to open up an EPIC this week with the work to clean up and commit those changes as well as open up issues for couple of features which we could not get time this semester to work on but would make this tool more robust.

Are there limitations to this tool? In particular, the implementation of reflect is changing to use MethodHandles. Does that change how this tool needs to transform the bytecode?

I would let @ShaneKilloran / @qasimy123 to provide more insights about the limitations they have identified.

@DanHeidinga In response to your second question, yes the tool is limited. It depends upon the current implementation of Method.invoke() within reflect. If there are changes to this implementation than we'd need to update the tool to alter the bytecode appropriately.

Another limitation is that it is only functional with tests run through junit and does not currently support other testing frameworks, although we hope to add this in the future.